This forum is closed to new posts and
responses. The content has been migrated to the Digital Solutions Community. Please join us there for new content as well as this content. For customer support, please visit the official HCL customer support channels below:
i detected a very massive Bug in Lotus Notes R5 and R6 (up to 6.02CF2, maybe also in 6.5 but no chance to test it on 6.5):
i am having an agent that updates Documents per ComputeWithForm. All of those documents are having relational fields in it (using @DBLookup). To get the documents to update it uses the db.FTSearch Method.
However, as there are very large databases, it often happens that update on all documents in one database takes quarter an hour. Now if the Agent creates the DocumentCollection it seems that there is also loaded all Document Content in Memory.
If now, the collection stays in memory, and some user changes the document (after the collection has been created) and saves his changes, they are all lost when the agent processes the document
Time Line:
- Agent creates documentcollection
- Agent starts updating doc by doc
- user changes document that is also in collection
- user saves document
- agent comes to document, saved by user and saves it
- changes made by the user are lost, there is even not Replication/Save Conflict
i tryed several things to make a workaround, but there is not function to avoid those. Even if i am destroying the collection, memoring the UNIDs and then processing the docs by GetDocumentByUNID gets also the document in memory at the time it was first touched by the agent.
For wondering a save conflict is created if the agent runs on another server, than the user has made his changes, but only when replication between the 2 servers happens after the agent has saved the document, if replication happens before, the data is also lost...
If anyone has a workaround on that, without changing the replication interval from imediate to anything else i would be very glad, this is a very very shitty problem and i will report this to IBM tomorrow.